Object copy/paste and read-only attribute values?

Tony_Goodman - Thu Feb 05 07:06:23 EST 2009
I don't think this is a problem - rather it is intended behaviour.

If the user is copying an object, he is doign just that, making an exact copy of the object which includes all attribute values.

Creating a new object is a different thing - the object will br created with default values (if set).

In either case the user cannot actually edit the attribute that is read only.

SystemAdmin - Thu Feb 05 09:51:34 EST 2009
Suppose a module has a boolean attribute called "Reviewed" and that only the "Reviewers" group has write access to that attribute. Other user just have read access. The default value for the "Reviewed" attribute is false. So when a user creates a new object in the module, the new object has a "Reviewed" value of false. And the only way the "Reviewed" attribute should get set to true is by some member of the "Reviewers" group.

But if the user copy/pastes an object with a "Reviewed" value of true, then the resulting object has a "Reviewed" value of true. The user can then change the other attributes as desired and have a new object that has been 'reviewed' even though no one in the "Reviewers" group has looked at it. Isn't that a problem?

Not that this specific example is what I'm trying to accomplish, but I think it does illustrate the problem.

Tony_Goodman - Thu Feb 05 10:27:09 EST 2009
I agree that this can be a problem, but I don't think it is a fault of the way doors works, Rather it is a problem with the user's perception of what they are doing. In this instance copying is not a valid method for creating new objects.

In my experience, it is generally better to trust your users rather than lock everything down and attempt to enforce a process using the tool. Maybe they should be allowed to edit the attribute, but should also be told that they must reset the attribute if they use copy/paste.

You could store review information in a separate module and link to the module being reviewed. That would solve your example, but would create more difficulty for the users.

A very good friend of mine once recommended using a rolled-up newspaper to control naughty users.

SystemAdmin - Thu Feb 05 13:16:00 EST 2009
Even if you trust the users, why subject them to the extra effort? Consider the suggested options:

1. Tell the users that they should not use object copy/paste. If the object(s) to created have much in common with existing object(s), then having to manually create the object(s) and populate each attribute individually is tedious.

2. Allow the user to use copy/paste, but expect that they edit each pasted object to manually reset certain attributes. Also tedious.

3. Don't use access rights on attribute values, instead store the attributes in linked objects in a separate module. Shifts the burden, but also tedious.

If access rights restrictions were honored during object paste operations, none of the above would be necessary.

JayWalker - Wed Feb 11 15:46:50 EST 2009
Unfortunately, access rights restrictions ARE honored in this example. You would be violating access rights if the value of the attribute CHANGES when a user with read only access for that 'attribute' copies and pastes the object.

I do see the value of restricting access rights on attributes, but when you copy an object within a module, you get everything.

I would guess that there is a DXL solution for that specific example. Such as looking into creating a trigger that changes the 'reviewed' attribute to 'unapproved' (or whatever) for any object that is edited or created.... so that all NEW or EDITED objects revert that attribute to default.... but I'm not sure that's what you are looking for.

Overall, I agree with Tony, that the tool is behaving as expected, and I haven't run into this as an issue at my company in my 12 years of use, and I do have a couple of modules with restricted attribute access. Typically if a user is copying an object, they WANT what is in the read locked attributes to remain the same, that's why they copy, otherwise they should create new.

Although having the in-links for approval is a clever way to handle it, and I don't think it's very complicated, or even difficult to manage for this use case (as a review status). You could even have the 'default' view in the module include an Analysis column, that would show the 'status' (based on link). And when a user COPIES an object, they will not copy the link, thus the column will be blank for that new object.... BRILLIANT!

llandale - Tue Feb 24 14:41:05 EST 2009
Read the thread, restarting indent.

I suspect you will find that other folks will complain if they copy an object and do not get the restricted attribute values. This Telelogic has to make a choice between the two behaviors; which they have done.

I'd like to point out you have a serious 'Reviewed' problem if such a user takes an existing 'Reviewed' object and modifies the text; that text has not been 'Reviewed' but the object has. The solution to THAT problem is to have an on-demand script run by your admins, that looks at the last modified date of all the 'reviewable' attributes and compares that to the last modified date of the 'Reviewed' attribute; showing objects that have been modified after Reviewed. This script would set the 'Reviewed' attribute, perhaps first setting it false and the setting it true, to make sure it gets a newer last-modified date. This script can no doubt be clever enough to find recently created objects and force them to be reviewed (perhaps the create date is the same as the review date).

It would be pretty trivial to write a 'copy object' utility that creates an object before/after the selected object copying all attribute values of some other object, perhaps the one marked in orange or the one currently selected as being 'copied', or perhaps on the clipboard. This would solve your problem since your typical users could not set the Reviewed status of the new object (via the script).

> Louie

SystemAdmin - Wed Feb 25 06:41:34 EST 2009
Sorry, perhaps I started this thread off incorrectly by discussing object copy/paste behavior. The real question is:

Suppose only users in Group_A are to be allowed to assign values to object attribute X in a module. How is that accomplished?

kbmurphy - Mon Mar 09 17:08:45 EDT 2009
For these situations I have found access rights won't work (the copy/paste example above, for instance)...so the answer is a trigger.

In your example, there's an attribute called reviewed. If reviewed==true but the user changes object text, the post object text trigger runs and sets reviewed to false. If the user tries to change it to true, a pre reviewed trigger checks to see if the user is in the proper group. If the user is all goes as normal. If not, an error occurs.

There is no other viable way I have found to do this, so I mostly do what Tony says--train and trust your users. You have history, so if a user does something they shouldn't, there's an audit trail and you can address it with that user.

SystemAdmin - Mon Mar 09 21:13:36 EDT 2009
Thanks for the suggestion. What trigger event do you rely on when an object is pasted? I tried object open/sync pre/post triggers and attribute save pre/post triggers, but none of those appear to 'fire' on an object paste operation.

SystemAdmin - Mon Mar 09 21:13:36 EDT 2009
Thanks for the suggestion. What trigger event do you rely on when an object is pasted? I tried object open/sync pre/post triggers and attribute save pre/post triggers, but none of those appear to 'fire' on an object paste operation.

kbmurphy - Tue Mar 10 11:57:03 EDT 2009
I don't believe there is a post-paste trigger. However, I think you may be worrying a little too much about this instance. Yes, it's a problem, but it's not the end of the world.

If I am a user, and I copy an object and then paste that object, my guess is that the very first thing I'm going to do is edit the object's text. As soon as I do that, the trigger runs.

While DOORS is very flexible, at some point you need to trust and train your users. This includes any manager who may be giving you these process requirements. The process should facilitate and not get in the way. Again, DOORS has built-in history and audit trails.

That being said, is copy/paste truly a dealbreaker?

SystemAdmin - Wed Mar 11 15:59:46 EDT 2009
Not a deal-breaker, but it is disappointing.

Object copy/paste should be functionally equivalent to performing the individual steps manually, but it isn't. The individual steps consist of:

1. Create a new 'paste' object
2. Set each edit-able attribute value of the new 'paste' object to match that of the 'copy' object.

If object copy/paste worked that way, then read-only attribute values could be achieved using access controls, with no need to rely on triggers, or trusting/training users, or constant auditing of changes.

I'm amazed no one else seems to see it that way.

kbmurphy - Fri Mar 13 15:57:21 EDT 2009
I understand what you are saying but in your case, why doesn't my solution work? Will your users just be copying and pasting a ton of stuff, and then not editing what they just pasted?

When I train users, I tell them to not use copy and paste too much. This isn't word, it's a database, and thus copy in DOORS is not akin to copy in Word, and neither is paste. As you've mentioned, there's quite a bit of logic that DOORS has to handle in order to figure out what to do.

I don't think anyone here is disagreeing with you outright--just some people say it makes sense and others not. I am telling you that a trigger is the way to go, because users should just not be blindly copying and pasting objects and then not editing them.

You'd need the trigger anyway even if copy and paste worked as you like, by the way, to account for changing the reviewed attribute from "Approved" to "Needs Approval" automatically. And for a user to be able to do that, they need to have M access to the attribute value and not be locked out.

I think you're focusing in on the wrong problem, but that's just my opinion.

SystemAdmin - Wed Mar 11 15:59:46 EDT 2009
Not a deal-breaker, but it is disappointing.

Object copy/paste should be functionally equivalent to performing the individual steps manually, but it isn't. The individual steps consist of:

1. Create a new 'paste' object
2. Set each edit-able attribute value of the new 'paste' object to match that of the 'copy' object.

If object copy/paste worked that way, then read-only attribute values could be achieved using access controls, with no need to rely on triggers, or trusting/training users, or constant auditing of changes.

I'm amazed no one else seems to see it that way.

SystemAdmin - Tue Mar 17 10:29:17 EDT 2009
Sorry for the delay in responding. I had hoped to do some testing of a trigger-based implementation of a read-only attribute, but I've been too busy lately.

Here are some of the concerns I have about a trigger-based solution:

1. There does not appear to be any trigger events associated with pasting a copied object, so some other trigger event must be used, but which one? Possibilities include object sync, attribute save, or module close.

2. Can the trigger script be made intelligent enough to only process just pasted objects?

3. If the user copy/pastes an object with hierarchy, can the trigger script be made intelligent enough to process the entire pasted hierarchy of objects?

4. Since the trigger-based implementation requires that the user have modify access to the protected attribute, how should attempts by the user to directly modify the protected attribute be handled?

5. How does one manage trigger-based restricted attributes across a database? How do others generate a report showing access restrictions (access rights plus trigger-based restricted attributes)?

I'm not really interested in the "Approved" to "Needs Approval" issue. All I'm asking for is an attribute that can only be set to a non-default value by someone in a specific group. Other users cannot modify the attribute value and they get the default attribute value when copy/pasting exising objects.

kbmurphy - Tue Mar 17 13:58:55 EDT 2009
I don't believe a trigger can run on copy/paste.

Also, you cannot set the value of the attribute as Read-only. It's "virtually" read-only due to the trigger.

Think about it...you have an approved requirement. Joe Engineer is not allowed to set that it was approved in DOORS--Jane Engineer has to do that. Joe then makes a change, and the trigger runs to set Approved to "Changed" or something.

The trigger attempts to do this AS JOE. Thus, Joe has to have access to modify the attribute value. Thus, Joe has to have RM on the value.

What the trigger does is determine if a change has been made to an approved requirement and then sets the value to approved for something else. If the attribute is Read-Only, it can't do that.

Good luck. This past weekend I had to do something very similar, and I was actually amazed that DOORS could handle it as well as it did. You may see in other postings on this forum I am quite down on DOORS, but I also give credit where its due--it let me do some customization for my client that I really thought I'd have to jump through hoops to get working.

SystemAdmin - Tue Mar 17 15:55:30 EDT 2009
Sorry I mentioned the example of a 'reviewed' attribute. That has derailed the discussion. Let me try approaching the problem from a different direction:

Can anyone think of a scenario where you would want to restrict certain users/groups to read-only access to the values of an object-level attribute?

kbmurphy - Tue Mar 17 17:22:42 EDT 2009
IMO, the 'reviewed' attribute has not derailed the discussion. I just implemented this very thing for a client this past weekend.

The Business Analysts write the requirements. They submit them. A PMO group approves them. The PMO group is the one that actually sets a requirement to be Approved. If the BA tries to do this they get a message saying, "Sorry, only the PMO group can do this." However, if the BA makes a change to any approved object, then the status gets set to "Not Approved" by a trigger.

I'm trying to help you by telling you that in the case above, the BA needs Modify access to the attribute value. Because without this access, the status cannot be set to "Not Approved".

Is that clear? I imagine this is very similar to what you are trying to accomplish.

SystemAdmin - Tue Mar 17 21:04:58 EDT 2009
I'm sure your implementation is quite clever and just the thing that was needed in that situation. However I would like to discuss read-only attribute values (note the subject of this thread). Is there ever a situation where you would want to restrict a group to having read-only access to the values of an object-level attribute?

llandale - Wed Mar 18 10:09:40 EDT 2009
Yes, there are times where you want certain groups to be able to edit some attr values, but not others. For example, the Test group can modify 'Verification Method' but not modify the requirement text itself.

SystemAdmin - Wed Mar 18 10:46:23 EDT 2009
So in that case, the Test group would probably not have the ability to create new objects in the module. Therefore object copy/paste behavior would not be an issue.

What about a situation where a group has read-only access to an attribute, but has the ability to create new objects in the module?

Perhaps system engineers are responsible for defining requirements and the program manager is responsible for assigning each requirement to a specific 'build'. In that case, the system engineers would need the ability to create new requirements, but should only have read access to the 'build' attribute. And shouldn't the 'build' attribute be blank for new requirements? Even when the new requirement is created by copying an existing requirement?

llandale - Wed Mar 18 11:22:03 EDT 2009
So we coming back full circle, what a surprise.

Even if you are absolutely correct in your opion on the behavior of object copying and there are no reasonable reasons for it to be otherwise, you should never-the-less accept the reality of the situation.

Copying read-only attribute values is a pretty trivial issue compared to what a clever evil person can do with DOORS. Heck, in v4 you could browse History of the 'users' module and print everyone's password.

Tell them not to copy objects when creating them; just like you tell the Req engineers not to purge 100s of requirements. If you want them to be able to make a new requirement look like an old one, then jeepers write them a DXL that creates the new object where they want and copies all the values they can write.

>Louie